Inside Macintosh: Open Transport /

Chapter 8 - TCP/IP Services

About the Open Transport DNR

The functions described in "Resolving Internet Addresses," beginning on page 8-40 and "Getting Information About an Internet Host," beginning on page 8-44 are implemented by the Open Transport domain name resolver (DNR). The DNR also implements the OTLookupName function (page 8-19) when you configure a TCP/IP mapper. The DNR can be invoked by a UDP endpoint's call to the OTSndUData function, a TCP endpoint's call to the OTConnect function, or a call to the OTResolveAddress function by either type of endpoint. This section describes how the Open Transport DNR operates.

When Open Transport loads TCP/IP, Open Transport initializes the DNR with a prioritized list of search domains, a prioritized list of name servers to be searched, and, if the user has a Hosts file, a list of name-to-address mappings and a list of canonical name-to-alias mappings from the Hosts file. Hosts files are described in "Using the Hosts File" on page 8-11.

When you request that the DNR resolve a name to an address, the DNR checks for a period (.) at the end of the name. If it finds one, the DNR assumes the name to be a fully qualified domain name and attempts to resolve it. If the name contains no periods, the DNR assumes that the name is partially qualified and begins a search in the first of the configured search domains. If the name contains at least one period, but doesn't have one at the end of the name, the DNR first assumes the name is fully qualified and attempts to resolve it as such. If that process fails, then the DNR assumes that the name is partially qualified and starts a search as for any other partially qualified name.

For each search domain, the DNR calls the configured name servers in the order specified during configuration. The DNR returns the first answer it finds and terminates the search. If there is no other way to resolve the name or if the DNR is looking for the name that corresponds to an address, it searches the root domain. The DNR abandons its search if it hasn't found the name in a predetermined amount of time.

The Open Transport DNR implements only the following DNS query types.

Type	Description
A	Resolve name to 32-bit IP host address.
HINFO	Return type of processor (CPU) and operating system of host.
MX	Return name of mail exchange for the domain.
PTR	Resolve address to a fully qualified domain name.

The Open Transport DNR does not cache negative responses or partial name resolutions from name servers; it depends on full-service name servers to fully resolve the name and then caches only the final resolved name.

The DNR always requests recursion (that is, it requests the name server it contacts to contact other name servers, as required, to completely resolve a name). However, if the name server does not perform recursion but does provide references to additional name servers, the DNR follows up on these references. The DNR does not save the name server references after the name resolution is complete; instead, it starts over each time with the configured name servers.

The DNR caches name-to-address and canonical name-to-alias mappings, but not host information (CPU and operating-system types) or the results of mail exchange (MX) queries.

Open Transport supports use of a Hosts file, which the DNR uses to supplement and customize its cache. The Hosts file is located in the Preferences folder in the System Folder. However, it is best to avoid using a Hosts file if a name server is available, as Hosts files usually waste memory in the local cache and degrade performance of the DNR. If you do use a Hosts file, keep it as short as possible. For more information about the Hosts file, see "Using the Hosts File" on page 8-11.